Subject: Elimination of LLC2 and extra SAPs

From: "jim (j.) cobban" <[email-masked]>
Date: Mon, 8 May 1995 17:47:00 -0400

Existing HPR implementations establish an LLC2 connection unconditionally.
They also use an LLC1 "connection".  However if two adjacent HPR capable
nodes both support the Rapid Transport Protocol (RTP) tower and the Control
Flows over RTP tower, then only dependent LU traffic (without DLUR) uses the
LLC2 connection.  If there is no such traffic, then the LLC2 connection
(using the original SAP pair also used for the XID negotiation) carries NO
traffic.  See section 5.1 of the architecture for reference.  The HPR node
is required to establish an LLC2 connection which will exchange nothing but
RRs as long as it is up.  IBM then argues that HPR nodes must use a different
SAP pair for the UI exchange in order to improve the performance of the
traffic which is carried over the UIs, by distinguishing it at the earliest
opportunity from non-existent traffic on the LLC2 pipe.  See section 6.2.2 for
reference.

Note that support for the two function towers is signalled in the CV 61.  The
two nodes therefore KNOW that they are not going to exchange any I frames.
And yet they still establish the LLC2 connection and still insist upon using
a different SAP for the LLC1 traffic.  Moreover if anything ever happens to
the LLC2 connection then the HPR pipe is taken down, even though there would
have been no traffic disruption.

If the requirement for establishing the LLC2 pipe were removed then the
maximum 255 LLC connection limit typical of most adapters is also eliminated.

Since in this situation it would be natural to use the same SAP pair for the
LLC1 data as for the XID connection, this data link transport could be
handled by the existing DLSw specification, where the use of different SAPs
for the UI traffic will cause HPR traffic to be improperly routed, if at all.

Since this sounds like a good idea for us, and probably others, I recommend
to the HPR SIG that the LLC2 connection be eliminated on LANs, Frame-Relay
and ATM in the case where the XID exchange establishes that it is not
necessary.  I propose the following test:

  - CV61 byte 2 bits 0-1 equal to either 01 or 10, since these values
    signal support of LLC1
  - CV61 byte 2 bits 2-3 equal to 11, signalling support of both RTP and
    control flows over RTP, since this eliminates the requirement for LLC2 to
    carry the CP-CP sessions.  It also means that all independent LU sessions
    are carried using NLPs.
  - XID3 byte 9 high order bit set to 1 indicating that the sender does not
    want to receive an ACTPU, and therefore does not require LLC2 for
    dependent LU sessions.
  - there is some risk of incompatibility with already shipped
    implementations.  I am personally so annoyed by IBM's attitude to this
    whole problem area, that I am tempted to ignore that case, and let IBM
    implementations fail.  If that is not acceptable to the SIG, then it is
    necessary to add an additional bit to byte 2 of the CV61 to indicate
    explicitly that the LLC2 connection is optional.

If an HPR station has both sent and received an XID with these settings, then
it will not establish the LLC2 connection and will ignore the setting or
default value of subfield 80.  If either station does not recognize this
configuration and sends a SABME anyway, the other station will issue DM.